Object Identifiers

SystemAdmin - Wed Dec 23 09:25:47 EST 2009
The object identifier is a combination of the module prefix and the absolute number.

So if you change the module prefix in the current version, the object identifier will be updated in the current version but NOT in the baselined one

Regards

SystemAdmin - Wed Dec 23 09:25:47 EST 2009
The object identifier is a combination of the module prefix and the absolute number.

So if you change the module prefix in the current version, the object identifier will be updated in the current version but NOT in the baselined one

Regards

Lion29 - Sat Jan 16 06:46:07 EST 2010
I tried to change the prefix of the module by checking the properties of the Module. But, the Prefix of the Module is a Read-Only Attribute. This can not be modified even in the baseline or in the current version of the Document.

I tried by creating a new formal module. Once the module is created, then the attribute becomes Read-only attribute for the Module.

ChrisAnnal - Tue Dec 29 09:19:59 EST 2009
Both Thom and KB's answers are correct, but I think Thom more directly answers your question, since you asked if it's possible to change the prefix of the Object Identifier in the "current" document. I assume you mean in the current baseline. If so, then you can change the "prefix" portion of the Object Identifier by simply choosing "Module Properties" and changing the module prefix attribute to whatever you want.

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Since a number of folks use the "Object Identifier" as their requirement numbers, here's a simple script that will create a new string attribute named "ReqNum" out of the combination of the Module Prefix and the Absolute Number of an object. The advantage of having a string attribute named "ReqNum" is that, as many who have tried know, you can't link very easily to objects by using the Object Identifier - since that attribute is really a combination of two attributes as described above. Feel free to use this if you need to create a single attribute to represent what was previously the Object Identifier.

//initialize variables
Object oCurrObject
Module oCurrModule = current
string sNewAttribute = null
string sModPrefix = oCurrModule."Prefix"
int iAbsoNum = null
//loop through every object in the module
for oCurrObject in oCurrModule do
{
//get the absolute number of the object
iAbsoNum = oCurrObject."Absolute Number"
//create a new attribute out of the module prefix and the absolute number
//attempting to cast the integer to a string here...
sNewAttribute = sModPrefix iAbsoNum ""
oCurrObject."ReqNum" = sNewAttribute
}

ChrisAnnal - Mon Jan 18 08:37:46 EST 2010
Here's a quick "How To" for modifying the module prefix attribute, which contributes to the "Object Identifier". This document assumes you have the needed access rights to the module/attribute and that you opened the module in Exclusive Edit.

Lion29 - Tue Jan 19 04:03:32 EST 2010
Wow... sounds great... :-)
Tried in one of the module that is created in the home database, it is working fine... :-)

Tried the same procedure steps to get tat done for the module which was imported from other database, that is, the module was not born here... :-). when tried for this, it was not working... it was a read-only attribute.

is there any relation between the naming and the place of birth, like the situation mentioned above???
Attached is the snapshot of the read-only attribute for the prefix.

ChrisAnnal - Tue Jan 19 09:00:55 EST 2010
Hi Lion,
To answer your question, it's possible that a module created in another database may have one or more of the following problems:
1. The permissions/access to the module or attributes in the module were set so that you don't have create or modify access to the prefix.
2. If this module from another database is an archive of a previous baseline, then DOORS would treat it like a sort of "snapshot" of the module, not allowing any modifications to any attributes. (I don't think that's the case here, but I'm listing it here as a possibility only).
3. Importing a database that has been archived normally doesn't change access to whatever attributes you had access to prior to archiving - so you may need to see if you can be added as someone with RMCD access to the specific modules in question from that (other) database. In other words, maybe that module was created in the other database where you don't exist - so your access to that module in your home database is affected when you try to modify that module, after importing it.

In regard to the screenshot document. I can see in the first screenshot that you have the "Prefix" attribute selected (it's highlighted in blue) and the "View/Edit" button is enabled, meaning you can use that button. In the second screenshot, I'm not sure what exactly I'm seeing. I can tell it has the same value set for the Module Prefix ("Script-"), but since the "Prefix" attribute isn't selected, I wouldn't expect to see the "View/Edit" button enabled. Are you saying that when you select the "Prefix" attribute on the second module, the "View/Edit" button remains disabled for that attribute? I think that's what you're trying to show, but since the attribute wasn't selected (highlighted in blue like the first screenshot), I can't say for sure.